Ch. 7 פרק 7 ניהול העלות בפרויקט תוכנה
ניהול עלות בפרויקט עלות הפרויקט מתייחסת להוצאות הכספיות שעל הפרויקט להוציא על מנת להביא להשלמתו ולהשגת יעדיו בפרויקטי תוכנה העלות העיקרית היא שכר העבודה ניהול עלות בפרויקט Project Cost Management תחום הידע העוסק בתהליכים ובפעילויות שבאמצעותם אומדים, מתקצבים ומבקרים עלויות, ושמאפשרים להשלים את הפרויקט במסגרת התקציב שאושר תהליכי ניהול עלות בפרויקט 1. אמידת עלויות מעקב ובקרה. 3 בקרת עלויות תכנון.2 סגירה ייזום קביעת תקציב ביצוע 2 ניהול העלות בפרויקט תוכנה
ניהול עלות בפרויקט: אמידת עלויות 1. אמידת עלויות מעקב ובקרה. 3 בקרת עלויות תכנון.2 סגירה ייזום קביעת תקציב ביצוע תשומות תפוקות אומדני עלות לפעילויות תוכנית בסיסית לתכולה בסיס האומדן לו"ז של פרויקט עדכון מסמכי הפרויקט תוכנית משאבי אנוש רשימת הסיכונים גורמים סביבתיים של הארגון נכסי תהליכים ארגוניים 3 ניהול העלות בפרויקט תוכנה
אמידת עלויות אמידת עלויות הוא התהליך בו מכינים קירוב של המשאבים הכספיים שנחוצים כדי להשלים את פעילויות הפרויקט אומדני עלות הם תחזיות המבוססות על המידע הידוע בנקודת זמן נתונה אמידת העלות מתחשבת בסיכונים ובניתוח חלופות יצור לעומת רכישה (make/buy) רכישה לעומת שכירה שימוש במשאבים משותפים שימוש חוזר (reuse) לעומת פיתוח חדש מרכיבי עלות אופייניים עבודה חומרים ציוד שירותים מתקנים אינפלציה עלויות שעת חירום אומדני העלות נעשים מדויקים יותר ככל שמתקדם הפרויקט, ולכן דורשים ליטוש ועדכון במהלך הפרויקט 4 ניהול העלות בפרויקט תוכנה
משפך אי-הודאות Uncertainty) *(Cone of סטיית הערכת העלות באבני דרך מקובלות בפרויקט תוכנה * Steve McConnell, Software Estimation, Microsoft Press, 2006 5 ניהול העלות בפרויקט תוכנה
ענן אי הודאות של האומדן הענן מתאר את טווח אי-ההתכנסות של משפך אי-הודאות במהלך הפרויקט כאשר הפרויקט אינו מנוהל היטב ומצב ההתקדמות )תכולה, מאמץ, לו"ז( אינו ברור לא ניתן לשפר את האומדנים ואי-הודאות נשארת גדולה 6 ניהול העלות בפרויקט תוכנה
אילוץ ההתכנסות של משפך אי-הודאות משפך אי הודאות אינו מתכנס מעצמו יש לנקוט בפעולות יזומות לגרום להתכנסותו פעולות אלה כוללות הכנת תוצרים המגדירים את תכולת הפרויקט ובכך מאפשרים אומדנים מדויקים יותר 7 ניהול העלות בפרויקט תוכנה
אומדן עלות של פרויקט תוכנה בפרויקטי תוכנה רבים נעשים האומדנים במונחי מאמץ, אבל... מחיר price עלות cost + רווח + תקורה אומדן עלויות צריך להתחיל מאומדן הגודל / ההיקף = מאמץ effort X רכש + תעריף = גודל / היקף size / scope פריון X =??? שעות עבודה $ $ 8 ניהול העלות בפרויקט תוכנה
אומדן גודל / היקף הפרויקט היקף פרויקט תוכנה ניתן לביטוי ככמות של מאפיינים שונים, כגון features סיפורי-לקוח "נקודות סיפור" points) (story דרישות Use Cases Function Points דפי אינטרנט )... מרכיבי GUI )חלונות, דיאלוגים, דוחות, טבלאות בסיסי-נתונים ממשקים מחלקות פונקציות / שגרות שורות קוד 9 ניהול העלות בפרויקט תוכנה
אומדנים מקובלים האומדנים המקובלים ביותר עבור גודל LOC = Lines Of Code מדד קלסי לגודל התוכנה KLOC = Kilo (1000) Lines Of Code NFP = Number of Function Points )היקף, אומדן הפונקציונאלית המוגדרת עבור מערכת התוכנה ניתן להמיר בין LOC מדד הגודל משמש כגורם ל- NFP נירמול למשל: מספר באגים ל- KLOC למדדים אחרים או ל- NFP נפח( התוכנה 10 ניהול העלות בפרויקט תוכנה
שורות קוד - (LOC) Lines of Code #include <stdio.h> int main(void) { printf("hello World"); return 0; } C COBOL 000100 IDENTIFICATION DIVISION. 000200 PROGRAM-ID. HELLOWORLD. 000300 000400* 000500 ENVIRONMENT DIVISION. 000600 CONFIGURATION SECTION. 000700 SOURCE-COMPUTER. RM-COBOL. 000800 OBJECT-COMPUTER. RM-COBOL. 000900 001000 DATA DIVISION. 001100 FILE SECTION. 001200 100000 PROCEDURE DIVISION. 100100 100200 MAIN-LOGIC SECTION. 100300 BEGIN. 100400 DISPLAY " " LINE 1 POSITION 1 ERASE EOS. 100500 DISPLAY "Hello world!" LINE 15 POSITION 10. 100600 STOP RUN. 100700 MAIN-LOGIC-EXIT. 100800 EXIT. קשיים באומדן ומדידה של שורות קוד הקוד הוא רק חלק קטן מהמאמץ הכולל של פיתוח תוכנה שפות שונות מספר שונה של שורות לא ברור מה בדיוק צריך לספור פקודות? הצהרות והגדרות נתונים? הערות? הוראות בקרה? שורות ששונו / נמחקו? לא כל מה שנכתב מסופק עם המוצר המספר המדויק ידוע רק כאשר המוצר הסתיים אומדן המבוסס על שורות קוד הוא עם סיכון כפול: תהליך האמידה מתחיל באומדן המוצר הסופי אומדן העלות מבוסס על אומדן הגודל הערכה לא-ודאית המבוססת על נתונים לא-ודאיים 11 ניהול העלות בפרויקט תוכנה
Function Points (FP)* מרכיבים של היישום הדורשים מימוש של פונקציות עיבוד - Function Transaction קלט חיצוני פונקציונליות External Inputs )EI( פלט חיצוני )EO( External Outputs שאילתות חיצוניות )EQ( External Inquiries סוגי FP פונקציות מידע - Function Data קבצים לוגיים פנימיים )ILF( Internal Logical Files קבצי ממשקים חיצוניים )EIF( External Interface Files ממציא השיטה: (1979) Albrecht A.J. השיטה מעוגנת כיום בתקן ISO ומתוחזקת ע"י קבוצת משתמשים IFPUG User domain External Input External Output External Inquiry Internal Logical File Application domain External Input External Output External Inquiry External Interface File External domain השיטה הומצאה עבור מערכות מידע קיימות התאמות של השיטה לסוגים שונים של מערכות ניתן ליישם את השיטה בהקשר של UML ותכנות מונחה עצמים * ממציא השיטה: IBM, 1979 A.J. Albrecht, 12 ניהול העלות בפרויקט תוכנה
שלב א' זיהוי וסיווג פונקציות סוג פונקציה משמעות קלט הנכנס אל תוך גבולות היישום ומפעיל עיבוד או עדכון של קובץ לוגי פנימי פלט היוצא אל מחוץ לגבולות היישום שילוב קלט/פלט )תגובה מיידית( דוגמאות בחירה מתפריט טופס נתונים Alt+Ctl+Del שליחת הודעה הפקת דו"ח העברת קובץ מחיקת פיסקה ממסמך הפעלה/עצירה של סרט מענה לשיחה נכנסת פרטים אישיים של משתמש מקבץ נתונים )לאו דווקא בקובץ/ DB נפרד( מסמך הנערך ע"י המשתמש מנקודת ראות המשתמש או גורם חיצוני רישום כניסות לאתר אחר External Input (EI) External Output (EO) External Inquiry (EQ) Internal Logical File (ILF) קובץ נתוני בדיקות מסך להצגת פרסומות פאנל חיווי של מערכת אזעקה מקבץ נתונים חיצוני המשמש את היישום לקריאה/כתיבה External Interface File (EIF) 13 ניהול העלות בפרויקט תוכנה
Albrecht s FP Example A Stock Control System J.A. Roberts is a company that sells 200 different electrical goods on the phone. To do this they want you to create a computerized stock control system. This system should have the following functionality: Allow the operator to enter an existing customers number or for new customers their details (up to 100 customers) Check the credit rating of customers and reject those with poor ratings Allow the operator to enter the goods being ordered. Check the availability of the goods being ordered. Where there are sufficient goods in stock supply all the goods Where there are not sufficient goods supply number available and create back order to be supplied when goods become available. Update the stock levels and customer account details. Produce Dispatch note and invoice. Update stock levels based on and delivery of goods. Update customer account details based on payment by a customer. 14 ניהול העלות בפרויקט תוכנה
Albrecht s Example זיהוי וסיווג של פונקציות External Inputs (EI) 1. Customer Number 2. New Customer Details 3. Order Details 4. Stock Delivery Details 5. Customer Payment Details 6. Main Menu Selection External Outputs (EO) 1. Credit Rating 2. Invoice 3. Dispatch Note 4. Customer Details Information 5. Order Details Information 6. Stock Details External Inquiries (EQ) 1. Customer Details Request 2. Order Details Request 3. Stock Details Request Internal Logical Files (ILF) 1. Goods Transaction File 2. Customer File 3. Goods File 4. Customer Transaction File 15 ניהול העלות בפרויקט תוכנה
שלב ב' - חישוב ערכים משוקללים איך קובעים זאת? Complexity = Low average High # of EI # of EO # of EQ # of ILF # of EIF x x x x x 3 4 3 7 5 4 5 4 10 7 6 7 6 15 10 = = = = = Total EI + Total EO + Total EQ + Total ILF + Total EIF Unadjusted Function Points - UFP 16 ניהול העלות בפרויקט תוכנה
קביעת רמת הסיבוכיות מספר הקבצים המתעדכנים בעקבות קלט/שאילתות External Input Complexity (EI,EQ) # of Data Element Types (DET) # of File Types Referenced (FTR) <5 5-15 >15 0-1 Low Low Average 2 Low Average High >2 Average High High External Output Complexity (EO,EQ) # of Data Element Types (DET) # of File Types Referenced (FTR) <6 6-19 >19 0-1 Low Low Average 2-3 Low Average High >3 Average High High מספר הסוגים השונים של נתונים מספר הקבצים שיש לעדכן באמצעות קלט/שאילתות מספר הסוגים השונים של רשומות בקבצים File Interface Complexity (ILF,EIF) # of Data Element Types (DET) # of Record Element Types (RET) 1-19 20-50 >50 1 Low Low Average 2-5 Low Average High >5 Average High High 17 ניהול העלות בפרויקט תוכנה
Albrecht s Example חישוב מספר FP גולמי Complexity = Low average High # of EI = 6 # of EO = 6 # of EQ = 3 # of ILF = 4 # of EIF = 0 x x x x x 3 4 3 7 5 4 5 4 10 7 6 7 6 15 10 = = = = = Total EI = 18 + Total EO = 24 + Total EQ = 9 + Total ILF = 28 + Total EIF = 0 Unadjusted Function Points (UFP) = 70 18 ניהול העלות בפרויקט תוכנה
תיקון על פי הערכת הסיבוכיות היחסית של היישום Relative Complexity Adjustment Factor (RCAF) No Subject Grade 1 Requirement for reliable backup and recovery 0 1 2 3 4 5 2 Requirement for data communication 0 1 2 3 4 5 3 Extent of distributed processing 0 1 2 3 4 5 4 Performance requirements 0 1 2 3 4 5 5 Expected operational environment 0 1 2 3 4 5 6 Extent of online data entries 0 1 2 3 4 5 7 Extent of multi-screen or multi-operation online data input 0 1 2 3 4 5 8 Extent of online updating of master files 0 1 2 3 4 5 9 Extent of complex inputs, outputs, online queries and files 0 1 2 3 4 5 10 Extent of complex data processing 0 1 2 3 4 5 11 Extent that currently developed code can be designed for reuse 0 1 2 3 4 5 12 Extent of conversion and installation included in the design 0 1 2 3 4 5 13 Extent of multiple installations in an organization and variety of customer organizations 0 1 2 3 4 5 14 Extent of change and focus on ease of use 0 1 2 3 4 5 RCAF = Total 31 NFP = UFP x )0.65 + 0.01 x RCAF( = 70 x (0.65 + 0.31) = 70 x 0.96 = 67.2 19 ניהול העלות בפרויקט תוכנה
היחס בין FP לשורות קוד 1 Function Point = 320 basic assembly language statements 213 macro assembler statements 128 C statements 107 COBOL statements 107 FORTRAN statements 80 PL/I statements 71 Ada 83 statements 64 C++ statements 54 Ada 95 32 Visual BASIC 16 PowerBuilder 13 SQL 22 Smalltalk statements 20 ניהול העלות בפרויקט תוכנה
FP משמשים לאומדן של מדדים אחרים NFP 1.15 NFP 1.2 NFP 1.25 NFP 0.4 approximate page counts for paper documents associated with a software project approximate number of test cases created approximate defect potential for new software projects NFP/150 approximate development schedule in calendar months approximate number of personnel required for the application NFP/750 approximate number of maintenance personnel required to keep the application updated 21 ניהול העלות בפרויקט תוכנה
כמה דוגמאות מהחיים...* Application NFP SLOC U.S. Air Traffic Control 306,324 65,349,222 Israeli air defense system 300,655 24,052,367 Iran's air defense system 260,100 23,780,557 Microsoft XP 126,788 8,114,400 American Express billing 20,141 1,432,238 Skype 21,202 1,130,759 Amazon web site 18,080 482,126 All-in-one printer 1,780 227,893 Bank ATM controls 3,625 178,484 Digital camera controls 1,285 82,243 Motorola cell phone 1,507 80,347 JAVA compiler 1,185 63,186 Nintendo Game Boy DS 1,002 53,455 LogiTech cordless mouse 736 39,267 ILOVEYOU computer worm 22 2,838 MYDOOM computer virus 8 1,045 * Capers Jones, A NEW BUSINESS MODEL FOR FUNCTION POINT METRICS, May 2008 22 ניהול העלות בפרויקט תוכנה
מאומדן גודל לאומדן מאמץ COnstructive COst MOdel = COCOMO B. Boehm, 1984 מורכב מ- 3 מודלים מודל לאומדן המוצר השלם מודל ביניים intermediate COCOMO מודל לאומדן המוצר למרכיביו המפורטים נתמקד ב- intermediate COCOMO 23 ניהול העלות בפרויקט תוכנה
Intermediate COCOMO נתון אומדן גודל המוצר המאמץ הנומינלי )S( Organic mode ב- KLOC )E חודשי אדם( מחושב כפונקציה של אופן הפיתוח פרוייקט תוכנה קטן ופשוט צוות מיומן ומנוסה דרישות מוגדרות Semi-detached mode פרויקט בינוני )גודל צוות מעורב מבחינת וסיבוכיות( נסיון דרישות שחלקן מוגדרות היטב וחלקן פחות Embedded mode אילוצים קשיחים של חומרה, תוכנה ותפעול את המספר הגולמי E יש לכייל לפי מספר מקדמי עלויות E = 2.4xS 1.05 E = 3.0xS 1.12 E = 2.8xS 1.20 (Cost Drivers) 24 ניהול העלות בפרויקט תוכנה
Intermediate COCOMO cost drivers 25 ניהול העלות בפרויקט תוכנה
- דוגמה Intermediate COCOMO תוכנת עיבוד תקשורת מבוססת מיקרו-פרוססור אמינות גבוהה דרישות ביצועים דרישות לו"ז דרישות ממשקים אופן הפיתוח embedded הערכת גודל 10,000 שורות קוד KLOC) 10) חישוב המאמץ הנומינלי: חודשי אדם = 44 1.20 2.8x(10) E = מקדמי עלויות drivers) (cost ראה להלן 26 ניהול העלות בפרויקט תוכנה
המאמץ המשוקלל Intermediate COCOMO חודשי אדם = 59 44 E = 1.35 x P i = 1.35 27 ניהול העלות בפרויקט תוכנה
- מסקנות Intermediate COCOMO אומדן המאמץ של הפרוייקט )59 ח"א( יכול לשמש כקלט לחישוב פרמטרים נוספים עלות כספית הערכת לו"ז התפלגות השלבים והפעילויות עלות המחשבים עלות אחזקה שנתית ועוד... המודל יושם בהצלחה במספר רחב של פרוייקטים אומדן על פי המודל נמצא מדוייק עד כדי 20% בכ- 70% מהמקרים המודל המדוייק ביותר לתקופתו )סוף שנות ה- 80 ( 28 ניהול העלות בפרויקט תוכנה
COCOMO II הרחבה של המודל המקורי 1995 מאפשר התייחסות לנושאים נוספים Object orientation Modern life-cycle models Rapid prototyping Fourth-generation languages COTS software COCOMO II הינו מודל מסובך ומורכב בהרבה מהקודם 29 ניהול העלות בפרויקט תוכנה
COCOMO II )המשך( שלושה מודלים נפרדים Application Composition Early design Post-architecture אותה נוסחה בסיסית: E = as b b מחושב על בסיס של 5 גורמים: PREC חדשנות: ניסיון קודם של הארגון במוצרים דומים גמישות: עד כמה הדרישות הן קשיחות. FLEX RESL רמת הסיכונים TEAM כישורי הצוות )CMM בשלות התהליכים )על פי מודל PMAT a הוא מכפלה של 17 כופלי עלות 30 ניהול העלות בפרויקט תוכנה
ניהול עלות בפרויקט: קביעת תקציב 1. אמידת עלויות מעקב ובקרה. 3 בקרת עלויות תכנון.2 סגירה ייזום קביעת תקציב ביצוע תשומות תפוקות תוכנית בסיסית לביצועי עלות אומדני עלות פעילות דרישות למימון הפרויקט בסיס אומדנים עדכונים למסמכי הפרויקט תוכנית בסיסית של התכולה לו"ז הפרויקט לוחות שנה למשאבים חוזים נכסי תהליכים ארגוניים 31 ניהול העלות בפרויקט תוכנה
קביעת תקציב קביעת תקציב הוא התהליך בו צוברים את אומדני העלויות של פעילויות נפרדות או של חבילות עבודה ויוצרים תכנית בסיסית מאושרת לעלויות קביעת התקציב מתבססת על התשומות הבאות אומדני עלות פעילות )בכל חבילת עבודה( בסיס אומדנים )הנחות ששימשו כבסיס לאומדני העלויות( תכנית בסיסית לתכולה )WBS( לו"ז הפרויקט לוחות שנה למשאבים חוזים נכסי תהליכים ארגוניים )למשל הנחיות אגף הכספים להכנת תקציב( לצורך קביעת התקציב משתמשים בטכניקות הבאות ריכוז עלויות Aggregation) (Cost ניתוח עתודות Analysis) (Reserve חוות דעת מומחים יחסים היסטוריים )קשרים שנמצאו בעבר בין מאפיין לבין גורמי עלות( התאמת מגבלות המימון )תיאום בין הכנסות להוצאות( 32 ניהול העלות בפרויקט תוכנה
תוכנית בסיסית לביצוע העלות Baseline) (Cost Performance תוכנית הבסיס לביצועי העלות מסתמכת על התקציב שאושר להשלמת הפרויקט BAC = Budget at Completion 3500 3000 דרישות מימון 2500 2000 בסיס ביצוע העלות 1500 1000 הוצאות 500 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 33 ניהול העלות בפרויקט תוכנה
ניהול עלות בפרויקט: בקרת עלויות 1. אמידת עלויות מעקב ובקרה. 3 בקרת עלויות תכנון.2 סגירה ייזום קביעת תקציב ביצוע תשומות תוכנית ניהול הפרויקט תפוקות מדדי ביצועי העבודה תחזיות לתקציב דרישות למימון הפרויקט עדכונים לנכסי תהליכים ארגוניים מידע על ביצוע העבודה בקשות לשינוי נכסי תהליכים ארגוניים עדכונים לתוכנית ניהול הפרויקט עדכונים למסמכי הפרויקט 34 ניהול העלות בפרויקט תוכנה
בקרת עלויות בקרת עלויות הוא התהליך בו עוקבים אחר מצב הפרויקט כדי לעדכן את תקציב הפרויקט וכדי לנהל שינויים בתוכנית הבסיסית לעלויות בעת בקרת עלויות בפרויקט משפיעים על הגורמים שמחוללים שינויים בתוכנית הבסיסית לעלויות מבטיחים שאת כל דרישות השינויים מבצעים בזמן הנכון מנהלים את השינויים בפועל בזמן שהם מתרחשים מבטיחים שבכל תקופה עלות ההוצאות לא גדולה מעלות המימון שאישרו ומבטיחים גם שעלות ההוצאות בכלל הפרויקט לא עולה על המימון שאישרו עוקבים אחר ביצועי העלות כדי לבודד ולהבין את הסטיות מהתוכנית הבסיסית המאושרת לעלויות עוקבים אחר ביצוע העבודה ביחס להוצאות הכספים מונעים משינויים שלא אושרו להיכלל בעלויות המדווחות או בניצול המשאבים מדווחים לכל בעלי העניין המתאימים על שינויים שאישרו ועל העלויות הקשורות בהם פועלים כדי שהחריגות הצפויות מהעלויות יהיו בגבולות מתקבלים על הדעת 35 ניהול העלות בפרויקט תוכנה
(Earned Value Management) בקרת עלויות בשיטת "ניהול ערך מזוכה" ניהול ערך מזוכה מתכנן ועוקב אחר שלושה ממדים עבור כל חבילת עבודה וסעיף בקרה ערך מתוכנן (Planned Value = PV) התקציב שאישרו ושהקצו עבור עבודה שיש להשלים על פעילות או מרכיב של מבנה תכולת העבודה סך כל הערך המתוכנן נקרא "תקציב בסיום" BAC) (Budget at Completion = ערך מזוכה (Earned Value = EV) ערך העבודה שבוצעה על פעילות או מרכיב של מבנה תכולת העבודה )במונחי התקציב( הערך המזוכה הנמדד מתייחס לתכנית הביצועים הבסיסית EV לא יכול להיות גדול מתקציב הערך המתוכנן המאושר עבור מרכיב כלשהו )מדוע?( עלות בפועל AC) (Actual Cost = סך העלות שנגרמה ונרשמה כשהשלימו עבודה על פעילות או מרכיב של מבנה תכולת העבודה סך העלות שנגרמה כשהשלימו את העבודה שהערך המזוכה מדד לעלות בפועל אין גבול עליון המדידה כוללת את כל העלות שנגרמה כדי להשיג את הערך המזוכה 36 ניהול העלות בפרויקט תוכנה
ערכים מצטברים 2010-2011, Dr. Amir Tomer (AC) (PV) ערך מזוכה,(EV) ערך מתוכנן ועלות בפועל כמה עלתה העבודה שבוצעה עד היום תקציב בסיום BAC = Budget At Completion עלות בפועל AC = Actual Cost מה "שווי" העבודה שתוכננה להתבצע עד היום כמה "שווה" העבודה שבוצעה עד היום ערך מזוכה EV = Earned Value זמן נקודת הבקרה 37 ניהול העלות בפרויקט תוכנה
ערכים מצטברים 2010-2011, Dr. Amir Tomer סטיות מהתוכנית ומדדי ביצוע סטיית לו"ז SV) (Schedule Variance = ההפרש בין הערך המזוכה לבין הערך המתוכנן SV = EV PV סטיית עלות CV) (Cost Variance = ההפרש בין הערך המזוכה לבין העלות בפועל CV = EV AC מדד ביצוע לו"ז Index) (Schedule Performance ההתקדמות שהושגה, יחסית להתקדמות המתוכננת SPI = EV/PV < 1 SPI : הפרויקט בפיגור לו"ז > 1 SPI : הפרויקט בהקדמת לו"ז מדד ביצוע עלות Index) (Cost Performance ערך העבודה שהושלמה יחסית לעלות שנגרמה בפועל )יעילות העבודה( CPI = EV/AC < 1 CPI : הפרויקט גירעוני > 1 CPI : הפרויקט חסכוני זמן SV PV AC EV CV BAC נקודת הבקרה כל המדדים ניתנים הן לחישוב נקודתי )עבור חבילת עבודה נתונה( והן לחישוב מצטבר )מתחילת הפרויקט( 38 ניהול העלות בפרויקט תוכנה
ניהול ערך מזוכה דוגמה PV פעילות )היום( מצב הפעילות EV AC 5,000 הפעילות הסתיימה 6,000 5,000 1 2,000 הפעילות הסתיימה 1,850 2,000 2 פעילות של 8,000 שעות, הסתיים "בערך חצי" 3,500 4,500 4,000 3 2,350 פעילות של 10,000 שעות התחילה לאחרונה 1,500 2,000 4 סה"כ 12,850 מה מצב הפרויקט? 13,850 13,000 39 ניהול העלות בפרויקט תוכנה
חישוב סטיות PV פעילות )היום( סטיות מהתוכנית EV AC CV = - 1,000 SV = 0 5,000 6,000 5,000 1 CV = + 150 SV = 0 2,000 1,850 2,000 2 CV = - 1,000 SV = - 500 3,500 4,500 4,000 3 CV = + 850 SV = + 350 2,350 1,500 2,000 4 CV = - 1,000 SV = - 150 12,850 13,850 סה"כ 13,000 40 ניהול העלות בפרויקט תוכנה
חישוב מדדי ביצוע PV פעילות )היום( סטיות מהתוכנית EV AC CPI =.82 SPI = 1.0 5,000 6,000 5,000 1 CPI = 1.08 SPI = 1.0 2,000 1,850 2,000 2 CPI =.77 SPI =.87 3,500 4,500 4,000 3 CPI = 1.56 SPI = 1.17 2,350 1,500 2,000 4 CPI =.92 SPI =.98 12,850 13,850 סה"כ 13,000 41 ניהול העלות בפרויקט תוכנה
חיזוי על בסיס הנתונים המצטברים לנקודת בקרה נתונה ניתן לחזות את אומדן הפרויקט ביום שיושלם: Estimate at Completion = EAC אומדן העבודה שנותרה עד להשלמת הפרויקט: Estimation to Complete = ETC ניתן לחשב זאת על בסיס הנחות שונות לגבי ההמשך, כדלהלן: Estimation at Completion EAC = Bottom-up ETC + AC EAC = AC + ETC EAC = BAC / Cumulative CPI EAC = AC + ETC Estimation to Complete Bottom-up ETC אומדן )מחדש( של כל הפעילויות שטרם הושלמו וסיכומן bottom-up ETC = BAC - EV ETC = EAC - AC ETC = (BAC EV) / (cumulative CPI x cumulative SPI) הנחת הבסיס אמידה מחדש של העבודה שנותרה הפרויקט "יעלה על הפסים" ויתנהל כמתוכנן מרגע זה ועד להשלמתו הפרויקט ימשיך במגמת הגירעון/החיסכון הנוכחית )על פי מדד ביצוע העלות המצטבר( הפרויקט ימשך בשתי מגמותיו: פיגור/הקדמה )על פי מדד ביצוע הלו"ז המצטבר( וגירעון/חיסכון )על פי מדד ביצוע העלות המצטבר( 42 ניהול העלות בפרויקט תוכנה
מדד ביצוע עד להשלמה TCPI) (To-Complete Performance Index = מדד זה חוזה מהם ביצועי העלות שיש להשיג בעבודה שנותרה, אם רוצים לעמוד ביעד ניהולי מסוים עמידה בתקציב המקורי להשלמה BAC היחס בין העבודה שנותרה לבין שארית התקציב המקורי TCPI = (BAC EV) / (BAC AC) עמידה באומדן ההשלמה של הפרויקט EAC היחס בין העבודה שנותרה לבין התקציב שנותר לפי האומדן החדש TCPI = (BAC EV) / (EAC AC) 43 ניהול העלות בפרויקט תוכנה
ניהול העלות בפרויקט תוכנה